Internet Engineering Task Force (IETF) M. Boucadair 


Request for Comments: 6977 X. Pougnard 
Category: Standards Track France Telecom 
ISSN: 2070-1721 July 2013 


Triggering DHCPv6é Reconfiguration from Relay Agents 
Abstract 


This document defines two new DHCPv6 messages: Reconfigure-Request 
and Reconfigure-Reply. The Reconfigure-Request message is sent by a 
DHCPv6 relay agent to notify a DHCPv6 server about a configuration 
information change, so that the DHCPv6 server can send a Reconfigure 
message accordingly. The Reconfigure-Reply message is used by the 
server to acknowledge the receipt of the Reconfigure-Request message. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6977. 


Copyright Notice 


Copyright (c) 2013 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 
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1. Introduction 


This document specifies two new DHCPv6 messages [RFC3315]: 
Reconfigure-Request and Reconfigure-Reply. 


Section 3 describes a typical problem scenario encountered that 
triggers the DHCPv6 server to issue a Reconfigure message when the 
configuration data is supplied by the relay agent. This problem may 
be encountered in other contexts. It is out of scope of this 
document to list all these cases. 


Section 4 describes the proposed solution that relies on the use of 
Reconfigure-Request and Reconfigure-Reply messages. The Reconfigure- 
Request message is sent by a DHCPv6 relay agent to notify a DHCPv6 
server about a configuration-information change, so that the DHCPv6 
server can send a Reconfigure message accordingly. The Reconfigure- 
Reply message is used by the server to acknowledge the receipt of 
Reconfigure-Request. 


Section 5 specifies the Link Address Option used by the relay agent 
to indicate the link on which the client is located to the server. 


Section 6 provides the detailed specification of the procedure to 
trigger Reconfigure messages by DHCPv6 relay agents. 
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2's 


Requirements Language 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


Problem Statement 


For cases where the DHCPv6 relay agent possesses some information 
that would be useful to the DHCPv6 client, [RFC6422] specifies a 
mechanism whereby the DHCPv6 relay agent can provide such information 
to the DHCPv6 server, which can, in turn, pass this information on to 
the DHCP client. This is achieved by use of RSOO (Relay-Supplied 
Options option), which carries configuration data to the DHCPv6 
server. The data conveyed in an RSOO is then sent back by the DHCPv6 
server to the requesting DHCPv6 client. 


An example of RSOO usage is shown in Figure 1; only a subset of 
exchanged DHCPv6 and RADIUS messages is represented. Figure 1 shows 
a broadband network scenario in which the Network Access Server (NAS) 
embeds a DHCPv6 relay agent. 


t------— + t atten + Ferren + 
|DHCPv6 | | Nas | |Radius | 
[Client | | (DHCPve6 | |Server | 
| | | Relay) | | | 
t------— + Fretes + FH + 
a=2 90l iCGrts ssn > 
| |---Access-Request---------- >| 


|<--Access-Accept------------ | 
l (e.g., DS-Lite-Tunnel-Name) | 


|Server | 


| 
| 
| 
| | 
—---Relay-Forward----------- > 
| (RSOO (OPTION_AFTR_NAME) ) 
| 
| | <--Re lay-Reply-------------- | 
|<--Advertise--------------- | (e.g., OPTION_AFTR_NAME) | 
| (e.g., OPTION_AFTR_NAME) | 


Figure 1: An Example of the RSOO Usage 
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A configuration change may result in an exchange of CoA (Change-of- 
Authorization) [RFC5176] messages between the NAS/DHCPv6 relay agent 
and Dynamic Authorization Client (DAC) server as shown in Figure 2. 
In this example, the NAS answers with a CoA-Ack message to notify the 
DAC that the CoA-Request has been successfully handled. 


Note that the change of the configuration in the DHCPv6 relay agent 
can be triggered by any other out-of-band mechanism. 


4+------- + parhne + 4+------- + 
|DHCPv6 | | Nas | |Radius | 
[Client | | (DHCP v6 | |Server/ | 
| | | Relay) | | pac 
pannia + 4+------- + Se + 
| | | 
{=m CoA-Request----------- 
(e.g., DS-Lite-Tunnel-Name) 
|------ CoA-Ack-------------- >| 


Figure 2: Change of Configuration 


Whenever the configuration information sent by the DHCPv6 relay agent 
to the DHCPv6 server changes, the DHCPv6 server has no means of 
detecting the change so that it can send a Reconfigure message 
accordingly. A solution is sketched in Section 4. 


4. Solution Overview 


To solve the problem described in Section 3, this document proposes a 
new DHCP message called Reconfigure-Request. In the example depicted 
in Figure 3, a Reconfigure-Request message is sent by the DHCPv6 
relay agent to a DHCPv6 server as soon as the configuration data 
conveyed in an RSOO has changed. Upon receipt of this message, and 
if it is configured to support such a mode, the DHCPv6 server must 
build Reconfigure-Reply and Reconfigure messages. Reconfigure-Reply 
is used to acknowledge the receipt of Reconfigure-Request. The 
Reconfigure message encapsulated in Relay-Reply is sent to the DHCPv6 
relay, which in turn will forward the message to the appropriate 
DHCPv6 client. 


This setup assumes the relay has a record of the client, so that it 
has enough information to send the Reconfigure-Request message to the 
server. How the state is recorded in the relay is out of scope of 
this document. For better resilience of the proposed solution, means 
to recover state in the event of failure (e.g., use of stable 
storage, DHCPv6 Bulk Leasequery [RFC5460]) need to be supported. 
These state recovery solutions are not discussed in this document. 
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4+------- + 4+------- + Setanta + 
|DHCPv6 | | Nas | [Radius | 
Client (DHCPv6 Server/ 
Relay) DAC 
4+------- + 4+------- + 4+------- + 
| | | 
|<----- CoA-Request=ss--===+= | 


<--Reconfigure-Reply-------- | 


il es r 
| |DHCPv6 | 
| |Server | 
| | | 
eae 
| 
| ---Reconfigure-Request----- > | 
| 
| 
| 


<--Réelay-Réply: sss rs Sases 
<--Reconfigure------------- | (Reconfigure) 


Figure 3: Flow Example with Reconfigure-Request 


The support of Reconfigure-Reply messages simplifies the 
retransmission procedure of the relay as it provides an explicit 
indication from the server (see Section 6.3 for more details). An 
alternative approach is the relay monitors’ Reconfigure messages 
received from the server to conclude whether or not the Reconfigure- 
Request was successfully handled. Nevertheless, this implicit 
approach may fail to achieve its goals in some cases: for example, 
the server accepts the request but it delays generating the 
corresponding Reconfigure messages due to its rate-limiting policies, 
the request was partially failed for some clients, etc. To avoid 
useless reconfigure cycles (e.g., due to the loss of Reconfigure- 
Reply messages), the approach adopted in this document allows the 
relay to correct the content of a retransmitted Reconfigure-Request 
based on some observed events (e.g., the client has retrieved the 
updated configuration). If the relay has no client to be 
reconfigured, it stops sending Reconfigure-Request messages. 


The Reconfigure-Request message can also be used in scenarios other 


than those that assume the use of RSOO. It is out of scope of this 
document to describe all these scenarios. 
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5. Link Address Option 


Figure 4 shows the format of the Link Address Option. 


0 1 2 3 
Ok 2 3.4.5 6°77 8°90 L233 4 62°78 9 Ord 2° 3.4 3) 6 78 9 OL 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
| OPTION_LINK_ADDRESS | option-len 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 


link-address (IPv6 address) 


+ ———— + — + 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Figure 4: Message Format of Link Address Option 
The description of the fields are as follows: 
option-code: OPTION_LINK_ADDRESS (80) 
option-len: 16 (octets) 


link-address: An IPv6 address used by the server to identify the 
link on which the client is located. 


The Link Address Option is used by the relay agent to indicate to the 
server the link on which the client is located. The relay agent MUST 
use a link-address value that is equivalent to the value used when 
relaying messages from the client to the server. Two link-address 
values are said to be equivalent if both values are IPv6 addresses 
that are on-link for the network link to which the client is 
connected. 


To defend against poor implementations that do not correctly evaluate 
equivalence, the relay agent SHOULD use the same value that was sent 
to the DHCPv6 server when relaying messages from the client to the 
server, as in Section 20.1.1 of [RFC3315]. 

6. Detailed Specification 

6.1. Messages Format 
Two new message type codes are defined: 


o RECONFIGURE-REQUEST (18) 


o RECONFIGURE-REPLY (19) 
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Reconfigure-Request and Reconfigure-Reply use the same format as 
defined in Section 6 of [RFC3315]. 

6.2. Messages Validation 

6.2.1. Reconfigure-Request 


Clients MUST silently discard any received Reconfigure-—Request 
messages. 


Servers MUST discard any received Reconfigure-Request messages that 
meet any of the following conditions: 


o the message does not include a Client Identifier Option [RFC3315]. 


o the message does not include a Link Address Option (Section 5). 


o the message includes a Server Identifier Option [RFC3315] but the 
contents of the Server Identifier Option do not match the server’s 
identifier. 


6.2.2. Reconfigure-Reply 


Clients and servers MUST silently discard any received Reconfigure- 
Reply messages. 


The relay MUST silently discard any received Reconfigure-Reply 
messages that meet any of the following conditions: 


o the "transaction-id" field in the message does not match the value 
used in the original message. 


o the message does not include a Server Identifier Option. 


o the message does not include a Status Code Option [RFC3315]. 


6.3. Creation and Transmission of a Reconfigure-Request 


For any event (e.g., modification of the configuration information) 
that requires the server to issue a Reconfigure message, the relay 
agent determines the client(s) affected by the change and then builds 
a Reconfigure-Request message: the relay agent sets the "msg-type" 
field to RECONFIGURE-REQUEST, generates a transaction ID, and inserts 
it in the "transaction-id" field. 


The relay agent MUST include one or more Client Identifier Options 
[RFC3315] and a Link Address Option (Section 5) so that the DHCPv6 
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server can identify the corresponding client and the link on which 
the client is located. 


The relay agent MAY include a Relay Identifier Option [RFC5460]. 


The relay agent MAY supply the updated configuration in the RSOO 
[RFC6422]. The relay agent MAY supply a Reconfigure Message Option 
to indicate which form of Reconfigure to use. The relay agent MAY 
include any option (e.g., Interface Identifier [RFC3315]) that it 
might insert when relaying a message received from a client. 


When several clients on the same link are affected by a configuration 
change, the relay MUST include several Client Identifier Options; 
each of these options identifies a specific client. If including the 
Client Identifier Options of all impacted clients exceeds the maximum 
message size (see Section 7), the relay MUST generate several 
Reconfigure-Request messages required to carry all Client Identifier 
Options. Rate-limit considerations are discussed in Section 7. 


The relay sets the destination address of the Reconfigure-Request 
message to the IP address it would have sent a Relay-Forward message 
(see Section 20 of [RFC3315]). 


In case multiple servers are configured to the relay agent, several 
Reconfigure-Request messages are to be built. The behavior of the 
relay agent to disambiguate responses when multiple servers are 
configured is implementation specific. For example, an 
implementation may generate a distinct "transaction-id" per server 
while another implementation may use the content of the "transaction- 
id" field and the Server Identifier Option to disambiguate the 
responses. 


The relay transmits Reconfigure-Request messages according to 
Section 14 of [RFC3315], using the following parameters: 


IRT (Initial retransmission time): 1 sec 
MRT (Maximum retransmission time): 10 secs 
MRC (Maximum retransmission count): 5 
MRD (Maximum retransmission duration): 0 


The relay MAY remove clients from the client identifier list in 
subsequent retransmissions, but MUST NOT add clients to the client 
identifier list. This decision is local to the relay (e.g., it may 
be based on observed events such as one or more clients were 
reconfigured on their own). 


The relay may receive Reconfigure encapsulated in Relay-Reply before 
Reconfigure-Reply. The relay SHOULD NOT interpret it as if the 
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Reconfigure-Request was successfully handled by the server. The 
relay SHOULD use Reconfigure-Reply, not the Reconfigure message, to 
determine if the request was successful (see the discussion in 
Section 4). 


6.4. Intermediate Relay Agents Behavior 


The relay agent MUST be configurable to accept or reject Reconfigure- 
Request messages received from other relay agents. If no indication 
is explicitly configured to the relay, the default behavior is to 
accept Reconfigure-Request messages. 


If the relay is configured not to allow Reconfigure-Request messages, 
the relay MUST silently discard any Reconfigure-Request message it 
receives. If the relay is configured to accept Reconfigure-Request 
messages, these messages are relayed as specified in Section 20.1.1 
of [RFC3315]. 


6.5. Server Behavior 


The server MUST be configurable to accept or reject Reconfigure- 


Request messages. If no indication is explicitly configured to the 
server, the default behavior is to reject Reconfigure-Request 
messages. 


Upon receipt of a valid Reconfigure-Request message from a DHCPv6 
relay agent (see Section 6.2), the server determines the client (s) 
for which a Reconfigure message is to be sent. 


The server constructs a Reconfigure-Reply message by setting the 
"msg-type" field to RECONFIGURE-REPLY and copying the transaction ID 
from the Reconfigure-Request message into the "transaction-id" field. 
The server includes its server identifier in a Server Identifier 
Option. The server MUST include a Status Code Option [RFC3315] 
indicating whether the request has been successfully processed, 
failed, or partially failed. 


o If the server fails to process the request, the server MUST set 
the Status Code Option to the appropriate status code (e.g., 


UnspecFail, NotAllowed, etc.). In particular, 


* UnspecFail MUST be returned if the Reconfigure-Request message 
is malformed. 


* NotAllowed MUST be returned if the server is not configured to 
allow Reconfigure-Request. 
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* NotConfigured MUST be returned if the server has no record of 
the link [RFC5007]. 


o If the Reconfigure-Request is successfully validated, the server 
MUST return a Status Code Option indicating "Success". In 
addition, the server MUST include a list of all the Client 
Identifier Options of the clients to which Reconfigure messages 
will not be sent (e.g., the server has no record of the client or 
the client did not negotiate for Reconfigure support). Note that 
this means that "Success" will be returned even if Reconfigure 
messages will not be sent to any of the clients. 


If RSOO is supplied, the server might use its content to double check 
whether a Reconfigure is required to be sent to the client. This 
assumes the server stored the content of RSOO it used to generate the 
configuration data sent to requesting clients. 


The server might use the content of the Reconfigure Message Option 
supplied by the relay agent to determine which form of Reconfigure to 
use. 


Then, the server MUST follow the procedure defined in Section 19.1 of 
[RFC3315] to construct a Reconfigure message. 


Rate-limit considerations are discussed in Section 7. 
6.6. Receipt of a Reconfigure-Reply 


Depending on the status code enclosed in a received Reconfigure-Reply 
message, the relay may decide to terminate the request (e.g., 
NotAllowed, NotConfigured, and Success) or try a different corrected 
Reconfigure-Request (e.g., UnspecFail). 


When multiple servers are configured, the relay should expect to 
receive several Reconfigure-Reply messages. As mentioned in 

Section 6.3, the relay should be able to disambiguate these responses 
and associate them with a given server. The relay agent assumes the 
request is successfully handled for a client if there is at least one 
Reconfigure-Reply message in which the corresponding Client 
Identifier Option does not appear. 


7. Rate-Limiting Considerations 


The relay MUST rate-limit Reconfigure-Request messages to be sent to 
the server. The relay MUST be configured with required rate-limit 
parameters. The maximum Reconfigure-Request packet size SHOULD be 
configurable and the default value MUST be 1280 octets. 
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The server MUST rate-limit Reconfigure messages triggered by 
Reconfigure-Request messages. The server MUST be configured with 
required rate-limit parameters. 


8. IANA Considerations 


IANA has assigned the following new DHCPv6 Message types in the 
registry maintained in 
http://www.iana.org/assignments/dhcpv6-parameters: 


RECONF IGURE-REQUEST 
RECONF IGURE-REPLY 


IANA has assigned the following new DHCPv6 Option Codes in the 
registry maintained in 
http://www.iana.org/assignments/dhcpv6-parameters: 


OPTION_LINK_ADDRESS 
9. Security Considerations 


Security considerations elaborated in [RFC3315] (in particular 
Section 21.1) and [RFC6422] must be taken into account. In addition, 
DHCPv6 servers MAY be configured to reject relayed Reconfigure- 
Request messages or restrict relay chaining (see [RFC5007] for more 
discussion about the rationale of this recommended behavior). 

Section 6.5 specifies the error code to return when the server is 
configured to reject Reconfigure-Request messages. 


Relay agents SHOULD implement appropriate means to prevent using 
Reconfigure-Request messages as a denial-of-service attack on the 
DHCPv6 servers. 


Because the Reconfigure-Request message provides a mechanism for 
triggering the DHCPv6 Reconfigure message, and the DHCPv6 Reconfigure 
message can raise security threats (e.g., to control the timing of a 
DHCPv6 renewal), the DHCPv6 server MUST have some mechanism for 
determining that the relay agent is a trusted entity. DHCPv6 servers 
and relay agents MUST implement relay message authentication as 


described in Section 21.1 of [RFC3315]. DHCPv6 servers MAY also 
implement a control policy based on the content of a received Relay 
Identifier Option [RFC5460]. Administrators are strongly advised to 


configure one of these security mechanisms. 
In an environment where the network connecting the relay agent to the 


DHCPv6 server is physically secure and does not contain devices not 
controlled by the server administrator, it may be sufficient to trust 
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the Relay Agent Identifier provided by the relay agent. In networks 
where the security of the machines with access to the data path is 
not under the control of the server administrator, IPsec [RFC4301] is 
necessary to prevent spoofing of Reconfigure-Request messages. 

DHCPv6 servers MUST silently discard Reconfigure-Request messages 
originating from unknown relay agents. 
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